Eric Anholt [Tue, 10 May 2016 00:28:18 +0000 (17:28 -0700)]
clk: bcm2835: Mark GPIO clocks enabled at boot as critical.
These divide off of PLLD_PER and are used for the ethernet and wifi
PHYs source PLLs. Neither of them is currently represented by a phy
device that would grab the clock for us.
This keeps other drivers from killing the networking PHYs when they
disable their own clocks and trigger PLLD_PER's refcount going to 0.
v2: Skip marking as critical if they aren't on at boot.
Noralf Trønnes [Sat, 3 Oct 2015 20:22:55 +0000 (22:22 +0200)]
dmaengine: bcm2835: Load driver early and support legacy API
Load driver early since at least bcm2708_fb doesn't support deferred
probing and even if it did, we don't want the video driver deferred.
Support the legacy DMA API which is needed by bcm2708_fb.
Don't mask out channel 2.
Noralf Trønnes [Wed, 3 Jun 2015 10:26:13 +0000 (12:26 +0200)]
ARM: bcm2835: Set Serial number and Revision
The VideoCore bootloader passes in Serial number and
Revision number through Device Tree. Make these available to
userspace through /proc/cpuinfo.
Mainline status:
There is a commit in linux-next that standardize passing the serial
number through Device Tree (string: /serial-number):
ARM: 8355/1: arch: Show the serial number from devicetree in cpuinfo
There was an attempt to do the same with the revision number, but it
didn't get in:
[PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
Phil Elwell [Wed, 24 Jun 2015 13:10:44 +0000 (14:10 +0100)]
spi-bcm2835: Support pin groups other than 7-11
The spi-bcm2835 driver automatically uses GPIO chip-selects due to
some unreliability of the native ones. In doing so it chooses the
same pins as the native chip-selects would use, but the existing
code always uses pins 7 and 8, wherever the SPI function is mapped.
Search the pinctrl group assigned to the driver for pins that
correspond to native chip-selects, and use those for GPIO chip-
selects.
Phil Elwell [Fri, 6 May 2016 11:32:47 +0000 (12:32 +0100)]
pinctrl-bcm2835: Return pins to inputs when freed
When dynamically unloading overlays, it is important that freed pins are
restored to being inputs to prevent functions from being enabled in
multiple places at once.
Phil Elwell [Thu, 26 Feb 2015 09:58:22 +0000 (09:58 +0000)]
pinctrl-bcm2835: Only request the interrupts listed in the DTB
Although the GPIO controller can generate three interrupts (four counting
the common one), the device tree files currently only specify two. In the
absence of the third, simply don't register that interrupt (as opposed to
registering 0), which has the effect of making it impossible to generate
interrupts for GPIOs 46-53 which, since they share pins with the SD card
interface, is unlikely to be a problem.
Phil Elwell [Tue, 24 Feb 2015 13:40:50 +0000 (13:40 +0000)]
pinctrl-bcm2835: Fix interrupt handling for GPIOs 28-31 and 46-53
Contrary to the documentation, the BCM2835 GPIO controller actually has
four interrupt lines - one each for the three IRQ groups and one common. Rather
confusingly, the GPIO interrupt groups don't correspond directly with the GPIO
control banks. Instead, GPIOs 0-27 generate IRQ GPIO0, 28-45 GPIO1 and
46-53 GPIO2.
Awkwardly, the GPIOS for IRQ GPIO1 straddle two 32-entry GPIO banks, so it is
cleaner to split out a function to process the interrupts for a single GPIO
bank.
This bug has only just been observed because GPIOs above 27 can only be
accessed on an old Raspberry Pi with the optional P5 header fitted, where
the pins are often used for I2S instead.
Noralf Trønnes [Fri, 12 Jun 2015 17:01:05 +0000 (19:01 +0200)]
irqchip: bcm2835: Add FIQ support
Add a duplicate irq range with an offset on the hwirq's so the
driver can detect that enable_fiq() is used.
Tested with downstream dwc_otg USB controller driver.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Phil Elwell [Fri, 4 Dec 2015 17:41:50 +0000 (17:41 +0000)]
irq-bcm2836: Prevent spurious interrupts, and trap them early
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Spurious interrupts are still possible for other reasons,
though, so trap them early.
Revert "sched/rt: Simplify the IPI based RT balancing logic"
This reverts commit 1c37ff78298a6b6063649123356a312e1cce12ca which is
commit 4bdced5c9a2922521e325896a7bbbf0132c94e56 upstream. This commit
removes two fields from struct rt_rq which is used in struct
sched_rt_entity, used in turn in struct task_struct. This turns into a
large ABI change for an enhancement fix, so revert that for now.
Gbp-Pq: Topic debian
Gbp-Pq: Name revert-sched-rt-Simplify-the-IPI-based-RT-balancing-.patch
Commit a9bfac14cde2 "bpf: prevent out-of-bounds speculation" added one
member each to struct bpf_map and struct bpf_array (which is
effectively a sub-type of bpf_map). Changing the size of struct
bpf_array is an ABI change, since the array contents immediately
follows the structure. However, bpf_map::work is not used (or even
initialised) until after the map's refcount drops to zero. We can
therefore move the new members into a union with it.
Based on the patch against 4.14.14 by Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name bpf-avoid-abi-change-in-4.9.77.patch
Revert "bpf: avoid false sharing of map refcount with max_entries"
This reverts commit 5cb917aa1f1e03df9a4c29b363e3900d73508fa8 which is commit be95a845cc4402272994ce290e3ad928aff06cb9 upstream. This commit heavily
modifies the bpf_map structure to split it on two cachelines and prevent
sharing reference counter with other, read-only fields in order to mitigate
Spectre attacks. This modification changes the ABI, so revert the mitigation
for now since the infrastructure is not yet complete for Spectre mitigation
anyway.
Gbp-Pq: Topic debian
Gbp-Pq: Name revert-bpf-avoid-false-sharing-of-map-refcount-with-.patch
Ben Hutchings [Wed, 29 Nov 2017 20:05:45 +0000 (20:05 +0000)]
mm/page_alloc: Avoid ABI change in 4.9.65
Commit d135e5750205 "mm/page_alloc.c: broken deferred calculation"
renamed pglist_data::static_init_size to static_init_pgcnt. However
the field has the same semantics as were intended originally (and in
any case, the field is only used by built-in code). Hide the renaming
from genksyms.
Gbp-Pq: Topic debian
Gbp-Pq: Name mm-page_alloc-avoid-abi-change-in-4.9.65.patch
Ben Hutchings [Thu, 16 Nov 2017 21:00:59 +0000 (21:00 +0000)]
netfilter: nat: Avoid ABI change in 4.9.63
Commit e1bf1687740c ("netfilter: nat: Revert "netfilter: nat: convert
nat bysrc hash to rhashtable") changed the type of
nf_conn::nat_bysource. Thankfully the two types are the same size,
and nothing outside of nf_nat_core touches this field directly. Hide
the change from genksyms but add compile-time assertions to make sure
that this isn't an ABI change.
Gbp-Pq: Topic debian
Gbp-Pq: Name netfilter-nat-avoid-abi-change-in-4.9.63.patch
Ben Hutchings [Sun, 29 Oct 2017 10:30:46 +0000 (10:30 +0000)]
KEYS: Limit ABI change in 4.9.59
Commit 363b02dab09b ("KEYS: Fix race between updating and finding a
negative key") rearranged various state members in struct key, resulting
in an ABI change for all keys APIs.
Only the keys subsystem and key type implementation use this state
information, so we can limit the ABI break to them:
- Renumber the other flags back to their old values
- Hide the deletion of the reject_error field from genksyms (it was only
used inside the keys subsystem)
- Move the new state field to the end of the structure and hide it from
genksyms
- Rename the register_key_type() function, so newly built key type
modules will only load on top of the new keys subsystem while old
key type modules will only load on top of the old keys subsystem
Gbp-Pq: Topic debian
Gbp-Pq: Name keys-limit-abi-change-in-4.9.59.patch
Ben Hutchings [Wed, 29 Nov 2017 19:54:22 +0000 (19:54 +0000)]
mmc: sdio: Avoid ABI change in 4.9.54
Commit 5ef1ecf060f2 "mmc: sdio: fix alignment issue in struct
sdio_func" changed the type of sdio_func::tmpbuf from array to
pointer. On 64-bit architectures this also changes the size of the
field. It appears that tmpbuf is only used by the MMC core, and the
structure is always allocated there. So put padding in the old
position, move the pointer to the end of the structure, and hide this
from genksyms.
Just in case I missed a user elsewhere, which might end up accessing
memory off the end of an old structure, rename the field to
core_tmpbuf (and update its users in the core).
Gbp-Pq: Topic debian
Gbp-Pq: Name mmc-sdio-avoid-abi-change-in-4.9.54.patch
Ben Hutchings [Sat, 28 Oct 2017 19:46:43 +0000 (20:46 +0100)]
mac80211: Avoid ABI change in 4.9.53
Commit 531682159092 ("mac80211: fix VLAN handling with TXQs") replaced
a union with two separate members in ieee80211_tx_info::control. The
one which changed offset (enqueue_time) doesn't appear to be accessed
outside of the mac80211 module, so this shouldn't be an ABI change for
drivers. Therefore hide the ABI change from genksyms.
Gbp-Pq: Topic debian
Gbp-Pq: Name mac80211-avoid-abi-change-in-4.9.53.patch
Ben Hutchings [Mon, 27 Nov 2017 20:49:07 +0000 (20:49 +0000)]
s390/mm: Avoid ABI change in 4.9.52
Commit 60f07c8ec5fa "s390/mm: fix race on mm->context.flush_mm" added
a field to the s390 definition of mm_context_t. This is embedded in
the arch-indepdendent struct mm_struct, so adding a new field results
in an incompatible change to the layout of the larger struct.
Move the new field out of mm_context_t to the end of mm_struct, and
hide the change from genksyms.
Gbp-Pq: Topic debian
Gbp-Pq: Name s390-mm-avoid-abi-change-in-4.9.52.patch
Ben Hutchings [Mon, 25 Sep 2017 23:03:33 +0000 (00:03 +0100)]
inet_frag: Limit ABI change in 4.9.51
Commit fb452a1aa3fd 'Revert "net: use lib/percpu_counter API for
fragmentation mem accounting"' changed the type of inet_frag::mem
from struct percpu_counter to atomic_t. There are few modules
that actually depend on this, but struct inet_frag is embedded in
various other structures that end up affecting symbol versions
for a huge number of networking APIs.
So add padding to keep the structure size unchanged, hide the type
change from genksyms, and rename a key inet_frag function so that
those modules that actually depend on the type of inet_frag::mem do
see an ABI change.
Gbp-Pq: Topic debian
Gbp-Pq: Name inet_frag-limit-abi-change-in-4.9.51.patch
Ben Hutchings [Mon, 25 Sep 2017 21:49:55 +0000 (22:49 +0100)]
ip6_fib: Avoid ABI change in 4.9.51
Commit c5cff8561d2d "ipv6: add rcu grace period before freeing
fib6_node" added an rcu_head field to the end of struct fib6_node.
As this structure is always allocated and freed inside of the ipv6
module (or built-in code), we can safely hide it from genksyms.
Gbp-Pq: Topic debian
Gbp-Pq: Name ip6_fib-avoid-abi-change-in-4.9.51.patch
Ben Hutchings [Tue, 14 Jun 2016 19:13:24 +0000 (20:13 +0100)]
liblockdep: Fix 'set but not used' warnings
liblockdep defines trivial macros for working with interrupt flags, as
interrupts are never disabled in userland. This results in warnings
from gcc when -Wunused-but-set-variable is enabled, and it is enabled
by -Wall. Fix this by evaluating the flags parameter and casting it to
void.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-fix-set-but-not-used-warnings.patch
Ben Hutchings [Tue, 14 Jun 2016 19:13:23 +0000 (20:13 +0100)]
liblockdep: Fix 'unused value' warnings
liblockdep defines various macros that may expand to an expression
with no effect, while the in-kernel definition does have an effect.
This results in warnings from gcc when -Wunused-value is enabled, and
is is enabled by -Wall. Fix this by introducing trivial functions,
as function return values are generally allowed to be ignored.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-fix-unused-value-warnings.patch
Ben Hutchings [Tue, 14 Jun 2016 20:09:19 +0000 (21:09 +0100)]
liblockdep: Fix undefined symbol prandom_u32
__lock_pin_lock() now calls prandom_u32() which is not defined in
liblockdep. __lock_pin_lock() and its caller lock_pin_lock() are dead
code in liblockdep, but we still need to provide a definition of
prandom_u32() in case lazy binding is disabled.
Fixes: e7904a28f533 ("locking/lockdep, sched/core: Implement a better ...") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-fix-undefined-symbol-prandom_u32.patch
Ben Hutchings [Thu, 9 Jun 2016 22:35:08 +0000 (23:35 +0100)]
cpupower: Bump soname version
Several functions in the libcpupower API are renamed or removed in
Linux 4.7. This is an backward-incompatible ABI change, so the
library soname should change from libcpupower.so.0 to
libcpupower.so.1.
Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name cpupower-bump-soname-version.patch
Ben Hutchings [Sun, 20 Mar 2016 21:09:02 +0000 (21:09 +0000)]
tools lib traceevent: Fix use of uninitialized variables
Fix a number of correct warnings from gcc:
> plugin_function.c:133:6: warning: 'index' may be used uninitialized in this function [-Wmaybe-uninitialized]
> int index;
> ^
'index' is initialized only if indentation is wanted. Move the
printing of indentation using 'index' into the same if-statement.
> kbuffer-parse.c:339:27: warning: 'length' may be used uninitialized in this function [-Wmaybe-uninitialized]
> kbuf->next = kbuf->index + length;
> ^
> kbuffer-parse.c:297:15: note: 'length' was declared here
> unsigned int length;
> ^
'length' is not initialized when handling an OLD_RINGBUF_TYPE_TIME_EXTEND
record. Based on what trace-cmd does, set length = 0 in this case.
> kbuffer-parse.c: In function 'kbuffer_read_at_offset':
> kbuffer-parse.c:632:9: warning: 'data' may be used uninitialized in this function [-Wmaybe-uninitialized]
> return data;
> ^
'data' is not initialized if the offset is too small. Initialize it
to NULL so that the behaviour is the same as when the offset is too
large.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-lib-traceevent-fix-use-of-uninitialized-variables.patch
Ben Hutchings [Sun, 21 Feb 2016 15:33:15 +0000 (15:33 +0000)]
tools/build: Remove bpf() run-time check at build time
It is not correct to test that a syscall works on the build system's
kernel. We might be building on an earlier kernel version or with
security restrictions that block bpf().
Also fix the test for whether __NR_bpf is defined.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-build-remove-bpf-run-time-check-at-build-time.patch
Ben Hutchings [Fri, 25 Sep 2015 19:28:10 +0000 (20:28 +0100)]
tools/hv: Fix fortify format warning
With fortify enabled, gcc warns:
tools/hv/hv_kvp_daemon.c:705:2: error: format not a string literal and no format arguments [-Werror=format-security]
snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
^
kvp_net_dir is a pointer to a string literal, but lacks const
qualification. As it is never modified, it should be a const
array rather than a pointer.
Also, while snprintf() has a bounds check, the following strcat()s
do not. Combine them into a single snprintf().
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name tools-hv-fix-fortify-format-warning.patch
Ben Hutchings [Fri, 25 Sep 2015 19:09:23 +0000 (20:09 +0100)]
tools/perf: Remove shebang lines from perf scripts
perf scripts need to be invoked through perf, not directly through
perl (or other language interpreter). So including shebang lines in
them is useless and possibly misleading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-perf-remove-shebangs.patch
Ben Hutchings [Fri, 2 Dec 2016 23:06:18 +0000 (23:06 +0000)]
module: Disable matching missing version CRC
This partly reverts commit cd3caefb4663e3811d37cc2afad3cce642d60061.
We want to fail closed if a symbol version CRC is missing, as the
alternative may allow subverting module signing.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name module-disable-matching-missing-version-crc.patch
Ben Hutchings [Fri, 2 Dec 2016 01:26:54 +0000 (01:26 +0000)]
powerpc: Fix missing CRCs, add yet more asm-prototypes.h declarations
Add declarations for:
- __mfdcr, __mtdcr (if CONFIG_PPC_DCR_NATIVE=y; through <asm/dcr.h>)
- switch_mmu_context (if CONFIG_PPC_BOOK3S_64=n; through <asm/mmu_context.h>)
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-fix-missing-crcs-add-yet-more-asm-prototypes.patch
Ben Hutchings [Fri, 2 Dec 2016 02:27:50 +0000 (02:27 +0000)]
powerpc: Remove Mac-on-Linux hooks
The symbols exported for use by MOL aren't getting CRCs and I was
about to fix that. But MOL is dead upstream, and the latest work on
it was to make it use KVM instead of its own kernel module. So remove
them instead.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-remove-mac-on-linux-hooks.patch
Commit 70a6fcf3283a "[sparc] unify 32bit and 64bit string.h" removed
the export of __memmove; don't try to export it again. It also
completely disabled declaration of prototypes of memscan, memcpy and
memset, which are defined as macros. gcc will still generate implicit
calls to memcpy and memset, so restore both exports and prototypes for
them. Don't restore the export of memscan.
Commit aa95ce361ed9 "sparc64: Delete __ret_efault." did what it says;
don't try to export that symbol.
Gbp-Pq: Topic bugfix/sparc
Gbp-Pq: Name revert-sparc-move-exports-to-definitions.patch
media: hdpvr: Fix an error handling path in hdpvr_probe()
Here, hdpvr_register_videodev() is responsible for setup and
register a video device. Also defining and initializing a worker.
hdpvr_register_videodev() is calling by hdpvr_probe at last.
So no need to flush any work here.
Unregister v4l2, free buffers and memory. If hdpvr_probe() will fail.
media: dvb-usb-v2: lmedm04: move ts2020 attach to dm04_lme2510_tuner
When the tuner was split from m88rs2000 the attach function is in wrong
place.
Move to dm04_lme2510_tuner to trap errors on failure and removing
a call to lme_coldreset.
Prevents driver starting up without any tuner connected.
Fixes to trap for ts2020 fail.
LME2510(C): FE Found M88RS2000
ts2020: probe of 0-0060 failed with error -11
...
LME2510(C): TUN Found RS2000 tuner
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
Mohamed Ghannam [Tue, 5 Dec 2017 20:58:35 +0000 (20:58 +0000)]
dccp: CVE-2017-8824: use-after-free in DCCP code
Whenever the sock object is in DCCP_CLOSED state,
dccp_disconnect() must free dccps_hc_tx_ccid and
dccps_hc_rx_ccid and set to NULL.
Signed-off-by: Mohamed Ghannam <simo.ghannam@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name dccp-cve-2017-8824-use-after-free-in-dccp-code.patch
Amey Telawane [Wed, 3 May 2017 10:11:14 +0000 (15:41 +0530)]
tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()
Strcpy is inherently not safe, and strlcpy() should be used instead.
__trace_find_cmdline() uses strcpy() because the comms saved must have a
terminating nul character, but it doesn't hurt to add the extra protection
of using strlcpy() instead of strcpy().
Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.org Signed-off-by: Amey Telawane <ameyt@codeaurora.org>
[AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10
https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=2161ae9a70b12cf18ac8e5952a20161ffbccb477] Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[ Updated change log and removed the "- 1" from len parameter ] Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tracing-Use-strlcpy-instead-of-strcpy-in-__trace_fin.patch
Ben Hutchings [Sun, 26 Feb 2017 21:01:50 +0000 (21:01 +0000)]
time: Mark TIMER_STATS as broken
This is a substitute for upstream commit dfb4357da6dd "time: Remove
CONFIG_TIMER_STATS", which avoids the need to resolve conflicts with
the PREEMPT_RT patch series.
Gbp-Pq: Topic debian
Gbp-Pq: Name time-mark-timer_stats-as-broken.patch
Ben Hutchings [Tue, 16 Feb 2016 02:45:42 +0000 (02:45 +0000)]
PCI: Set pci=nobios by default
CONFIG_PCI_GOBIOS results in physical addresses 640KB-1MB being mapped
W+X, which is undesirable for security reasons and will result in a
warning at boot now that we enable CONFIG_DEBUG_WX.
This can be overridden using the kernel parameter "pci=nobios", but we
want to disable W+X by default. Disable PCI BIOS probing by default;
it can still be enabled using "pci=bios".
Gbp-Pq: Topic debian
Gbp-Pq: Name i386-686-pae-pci-set-pci-nobios-by-default.patch
Linn Crosetto [Tue, 30 Aug 2016 17:54:38 +0000 (11:54 -0600)]
arm64: add kernel config option to set securelevel when in Secure Boot mode
Add a kernel configuration option to enable securelevel, to restrict
userspace's ability to modify the running kernel when UEFI Secure Boot is
enabled. Based on the x86 patch by Matthew Garrett.
Determine the state of Secure Boot in the EFI stub and pass this to the
kernel using the FDT.
Signed-off-by: Linn Crosetto <linn@hpe.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name arm64-add-kernel-config-option-to-set-securelevel-wh.patch
Linn Crosetto [Mon, 22 Feb 2016 19:54:37 +0000 (12:54 -0700)]
arm64/efi: Disable secure boot if shim is in insecure mode
Port to arm64 a patch originally written by Josh Boyer for the x86 EFI
stub.
A user can manually tell the shim boot loader to disable validation of
images it loads. When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set. Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.
Signed-off-by: Linn Crosetto <linn@hpe.com> Cc: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name arm64-efi-disable-secure-boot-if-shim-is-in-insecure.patch
Ben Hutchings [Thu, 2 Jun 2016 23:48:39 +0000 (00:48 +0100)]
mtd: Disable slram and phram when securelevel is enabled
The slram and phram drivers both allow mapping regions of physical
address space such that they can then be read and written by userland
through the MTD interface. This is probably usable to manipulate
hardware into overwriting kernel code on many systems. Prevent that
if securelevel is set.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name mtd-disable-slram-and-phram-when-securelevel-is-enabled.patch
Linn Crosetto [Wed, 16 Mar 2016 20:43:33 +0000 (14:43 -0600)]
acpi: Disable APEI error injection if securelevel is set
ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features. If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.
Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors. This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.
While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
securelevel is set.
Signed-off-by: Linn Crosetto <linn@hpe.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-disable-apei-error-injection-if-securelevel-is-.patch
Linn Crosetto [Fri, 4 Mar 2016 23:08:24 +0000 (16:08 -0700)]
acpi: Disable ACPI table override if securelevel is set
From the kernel documentation (initrd_table_override.txt):
If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
to override nearly any ACPI table provided by the BIOS with an
instrumented, modified one.
When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space. ACPI tables contain code invoked by the kernel, so
do not allow ACPI tables to be overridden if securelevel is set.
Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.7: ACPI override code moved to drivers/acpi/tables.c]
[bwh: Forward-ported to 4.9: adjust context]
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-disable-acpi-table-override-if-securelevel-is-s.patch
Dave Young [Tue, 6 Oct 2015 12:31:31 +0000 (13:31 +0100)]
kexec/uefi: copy secure_boot flag in boot params across kexec reboot
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot. Adding a patch to fix this by retain the secure_boot flag
in original kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name kexec-uefi-copy-secure_boot-flag-in-boot-params-acro.patch
Josh Boyer [Fri, 20 Jun 2014 12:53:24 +0000 (08:53 -0400)]
hibernate: Disable when securelevel is set
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the securelevel trust model,
so until we can work with signed hibernate images we disable it in
a secure modules environment.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name hibernate-disable-when-securelevel-is-set.patch
Josh Boyer [Wed, 6 Feb 2013 00:25:05 +0000 (19:25 -0500)]
efi: Disable secure boot if shim is in insecure mode
A user can manually tell the shim boot loader to disable validation of
images it loads. When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set. Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name efi-disable-secure-boot-if-shim-is-in-insecure-mode.patch
Matthew Garrett [Fri, 9 Aug 2013 22:36:30 +0000 (18:36 -0400)]
Add option to automatically set securelevel when in Secure Boot mode
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that the kernel prevent userspace from inserting untrusted kernel
code at runtime. Add a configuration option that enforces this automatically
when enabled.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name add-option-to-automatically-set-securelevel-when-in-.patch
Matthew Garrett [Fri, 9 Mar 2012 13:46:50 +0000 (08:46 -0500)]
asus-wmi: Restrict debugfs interface when securelevel is set
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel. Prevent that if securelevel is set.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name asus-wmi-restrict-debugfs-interface-when-securelevel.patch
Matthew Garrett [Fri, 8 Feb 2013 19:12:13 +0000 (11:12 -0800)]
x86: Restrict MSR access when securelevel is set
Permitting write access to MSRs allows userspace to modify the running
kernel. Prevent this if securelevel has been set. Based on a patch by Kees
Cook.
Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name x86-restrict-msr-access-when-securelevel-is-set.patch
Matthew Garrett [Tue, 3 Sep 2013 15:23:29 +0000 (11:23 -0400)]
uswsusp: Disable when securelevel is set
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if securelevel
has been set.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name uswsusp-disable-when-securelevel-is-set.patch
Matthew Garrett [Fri, 9 Aug 2013 07:33:56 +0000 (03:33 -0400)]
kexec: Disable at runtime if securelevel has been set.
kexec permits the loading and execution of arbitrary code in ring 0, which
permits the modification of the running kernel. Prevent this if securelevel
has been set.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name kexec-disable-at-runtime-if-securelevel-has-been-set.patch
Josh Boyer [Mon, 25 Jun 2012 23:57:30 +0000 (19:57 -0400)]
acpi: Ignore acpi_rsdp kernel parameter when securelevel is set
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to execute arbitrary code in the kernel.
Disable this when securelevel is set.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-ignore-acpi_rsdp-kernel-parameter-when-securele.patch
Matthew Garrett [Fri, 9 Mar 2012 13:39:37 +0000 (08:39 -0500)]
acpi: Limit access to custom_method if securelevel is set
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to modify the kernel at runtime. Prevent this
if securelevel has been set.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-limit-access-to-custom_method-if-securelevel-is.patch
Matthew Garrett [Fri, 9 Mar 2012 14:28:15 +0000 (09:28 -0500)]
Restrict /dev/mem and /dev/kmem when securelevel is set.
Allowing users to write to address space provides mechanisms that may permit
modification of the kernel at runtime. Prevent this if securelevel has been
set.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
[bwh: Forward-ported to 4.9: adjust context]
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name restrict-dev-mem-and-dev-kmem-when-securelevel-is-se.patch
Matthew Garrett [Thu, 8 Mar 2012 15:35:59 +0000 (10:35 -0500)]
x86: Lock down IO port access when securelevel is enabled
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down when securelevel is set.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name x86-lock-down-io-port-access-when-securelevel-is-ena.patch
Matthew Garrett [Thu, 8 Mar 2012 15:10:38 +0000 (10:10 -0500)]
PCI: Lock down BAR access when securelevel is enabled
Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to modify
kernel code. This should be prevented if securelevel has been set. Default
to paranoid - in future we can potentially relax this for sufficiently
IOMMU-isolated devices.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name pci-lock-down-bar-access-when-securelevel-is-enabled.patch
Matthew Garrett [Mon, 9 Sep 2013 12:46:52 +0000 (08:46 -0400)]
Enforce module signatures when securelevel is greater than 0
If securelevel has been set to 1 or greater, require that all modules have
valid signatures.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name enforce-module-signatures-when-securelevel-is-greate.patch
I decided to add a new expression, given that this doesn't fit into the
existing set operation. Notrack doesn't need a source register, and an
hypothetical NFT_CT_NOTRACK key makes no sense since matching the
untracked state is done through NFT_CT_STATE.
I'm placing this new notrack expression into nft_ct.c, I think a single
module is too much.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Gbp-Pq: Topic features/all
Gbp-Pq: Name netfilter-nft_ct-add-notrack-support.patch
Dongli Zhang [Wed, 1 Nov 2017 01:46:33 +0000 (09:46 +0800)]
xen/time: do not decrease steal time after live migration on xen
After guest live migration on xen, steal time in /proc/stat
(cpustat[CPUTIME_STEAL]) might decrease because steal returned by
xen_steal_lock() might be less than this_rq()->prev_steal_time which is
derived from previous return value of xen_steal_clock().
For instance, steal time of each vcpu is 335 before live migration.
Since runstate times are cumulative and cleared during xen live migration
by xen hypervisor, the idea of this patch is to accumulate runstate times
to global percpu variables before live migration suspend. Once guest VM is
resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
runstate times and previously accumulated times stored in global percpu
variables.
Comment above HYPERVISOR_suspend() has been removed as it is inaccurate:
the call can return an error code (e.g., possibly -EPERM in the future).
Similar and more severe issue would impact prior linux 4.8-4.10 as
discussed by Michael Las at
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
which would overflow steal time and lead to 100% st usage in top command
for linux 4.8-4.10. A backport of this patch would fix that issue.
[boris: added linux/slab.h to driver/xen/time.c, slightly reformatted
commit message]
References: https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name xen-time-do-not-decrease-steal-time-after-live-migra.patch
Ben Hutchings [Thu, 30 Nov 2017 00:29:18 +0000 (00:29 +0000)]
mmap: Add an exception to the stack gap for Hotspot JVM compatibility
The Hotspot JVM can easily exhaust the default stack, and has a
SIGSEGV handler to cope with this by switching to a new stack segment.
However, on i386 it creates a single writable and executable page just
under the stack limit as a workaround for a bug in Exec Shield. That
together with the enlarged stack gap causes the SIGSEGV handler to be
triggered when the stack pointer is further away from the stack limit,
and it doesn't recognise this as being a stack overflow.
This specifically affects programs that use JNI. Hotspot doesn't
normally run Java code on the initial thread.
Reduce the effective stack guard gap on x86 if the previous vma is
a single page allocated as MAP_FIXED.
References: https://bugs.debian.org/865303 Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name mmap-add-an-exception-to-the-stack-gap-for-hotspot-jvm.patch
projects / linux-4.9.git / log